作者：给立乐*
出处：http://spencer-dev.com/2017/07/12/Clean Code - Chapter 11 系统
声明：本文采用以下协议进行授权： 自由转载-非商用-非衍生-保持署名|Creative Commons BY-NC-ND 3.0 ，转载请注明作者及出处。

系统

“复杂要人命。它消磨开发者的生命，让产品难以规划、构建和测试” - Ray Ozzie，微软公司首席技术官

如何建造一个城市

你能自己掌管一切细节吗？大概不行。即便是管理一个既存的城市，也是一个人无法做到的。不过，城市还是在运转（多数时候）。

因为每个城市都有一组组人管理不同的部分，供水系统、供电系统、交通、执法、立法，诸如此类。有些人负责全局，其他人负责细节。

城市能运转，还因为它演化出恰当地抽象等级和模块，好让个人和他们所管理的“组件”即便在不了解全局时也能有效地运转。

尽管软件团队往往也是这样组织起来，但他们所致力的工作却常常没有同样的关注切分及抽象层级。整洁的代码帮助我们在较低层的抽象层级上达成一个目标。本章将讨论如何在较高的抽象层级 - 系统层级 - 上保持整洁。

将系统的构造与使用分开

首先，构造与使用是非常不一样的过程。

软件系统应将启始过程和启始过程之后的运行时逻辑分离开，在启始过程中构建应用对象，也会存在互相缠结的依赖关系。

每个应用程序都该留意启始过程。那也是本章中我们首要考虑的问题。将关注的方面分离开，是软件技艺中最古老也最重要的设计技巧。

不幸的是，多数应用都没有做到分离处理。启始过程代码很特殊，被混杂到运行时逻辑中。下例就是典型的情形：

1
2
3
4
5
6
7

public Service getService() {
        if (service == null){
            service = new MyServiceImpl(...);
        }
        return service;
        // 这种默认值大多数情况下都足够好吗？
    }

这就是所谓的延迟初始化／赋值，也有一些好处。在真正用到对象之前，无需操心这种架空构造，启始时间也会更短，而且还能保证永远不会返回 null 值。

然而，我们也得到了 MyServiceImpl 及其构造所需一切的硬编码依赖。不分解这些依赖关系就无法编译，即便在运行时永不使用这种类型的对象。

如果 MyServiceImpl 是各个重型对象，则测试也会是个问题。我们必须确保在单元测试调用该方法之前，就给 service 指派恰当的测试替身（TEST DOUBLE）或仿制对象（MOCK OBJECT）。由于构造逻辑与运行过程相混杂，我们必须测试所有的执行路径（例如，null 值测试及其代码块）。有了这些权责，说明方法做了不止一件事，这样就略微违反了单一权责原则。

最糟糕的大概是我们不知道 MyServiceImpl 在所有情形中是否都是正确的对象。我在代码注释中做了暗示。为什么该方法所属类必须知道全局情景？我们是否真能知道在这里要用到的正确对象？是否真有可能存在一种放之四海而皆准的类型？

当然，仅出现一次的延迟初始化不算是严重问题。不过，在应用程序中往往有许多种类似的情况出现。于是，全局设置策略（如果有的话）在应用中四散分布，缺乏模块组织性，通常也会有许多重复代码。

如果我们勤于打造有着良好格式并且强固的系统，就不该让这类就手小技巧破坏模块组织性。对象构造的启始和设置过程也不例外。应当将这个过程从正常的运行时逻辑中分离出来，确保拥有解决主要依赖问题的全局性一贯策略。

分解 main

将构造与使用分开的方法之一是将全部构造过程搬迁到 main 或被称之为 main 的模块中，设计系统的其余部分时，假设所有对象都已正确构造和设置。

控制流程很容易理解。main 函数创建系统所需的对象，在传递给应用程序，应用程序只管使用。

工厂

当然，有时应用程序也要负责确定何时创建对象。比如，在某个订单处理系统中，应用程序必须创建 LineItem 实体，添加到 Order 对象。在这种情况下，我们可以使用抽象工厂模式让应用自行控制何时创建 LineItems，但构造的细节却隔离于应用程序代码之外。

依赖注入

有一种强大的机制可以实现分离构造与使用，那就是依赖注入（Dependency Injection，DI），控制反转（Inversion of Control，IoC）在依赖管理中的一种应用手段。控制反转将第二责权从对象中拿出来，转移到了另一个专注于此的对象中，从而遵循了单一权责原则。在依赖管理情景中，对象不应该负责实体化对自身的依赖。反之，它应当将这份权责移交给其他“有权利”的机制，从而实现控制的反转。因为初始设置是一种全局问题，这种授权机制通常要么是 main 例程，要么是有特定目的的容器。

JNDI 查找是 DI 的一种“部分”实现。在 JNDI 中，对象请求目录服务器提供一种符合某个特定名称的“服务”。

1

MyService myService = (MyService)(jndiContext.lookup("NameOfMyService"));

调用对象并不控制真正返回对象的类别（当然前提是它实现了恰当的接口），但调用对象仍然主动分解了依赖。

真正的依赖注入还要更进一步。类并不直接分解其依赖，而是完全被动的。它提供可用与注入依赖的赋值器方法或构造器参数（或二者皆有）。在构造过程中，DI 容器实体化需要的对象（通常按需创建），并使用构造器参数或复制器方法将依赖连接到一起。只与哪个依赖对象真正得到使用，是通过配置文件或在一个有特殊目的的构造模块中编程决定。

Spring 框架提供了最有名的 Java DI 容器。用户在 XML 配置文件中定义互相关联的对象，然后用 Java 代码请求特定的对象。

但延后初始化的好处是什么？这种手段在 DI 中也有其作用。首先，多数 DI 容器在需要对象之前并不构造对象。其次，许多这类容器提供调用工厂或构造代理的机制，而这种机制可为延迟赋值或类似的优化处理所用。

扩容

城市有城镇而来，城镇由聚居而来。一开始，道路狭窄，几乎无人涉足，随后逐渐拓宽。小型建筑和空地渐渐被更大的建筑所取代，一些地方最终矗立起摩天大楼。

一开始，供电、供水、下水、互联网等服务全部欠奉。随着人口和建筑物密度的增加 ，这些服务也开始出现。

这种成长并非全无阵痛。你有多少次开着车，艰难穿行过一个“道路改善”工程，问自己，“他们为什么不一开始就修一条足够宽的路呢？”

不过那无论如何都不可能实现。谁敢打包票说在一个小镇修建一条六车道的公路并不浪费呢？谁会想要这么一条穿过他们小镇的路呢？

“一开始就做对系统”纯属神话。反之，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新用户的故事。这就是迭代和增量敏捷的精髓所在。测试驱动开发、重构以及它们打造出的整洁代码，在代码层面保证了这个过程的实现。

但在系统层面又如何？难道系统架构不需要预先做好计划吗？系统理所当然不可能从简单递增到复杂，它能行吗？

软件系统与物理系统可以类比。它们的架构都可以递增式地增长，只要我们持续将关注面恰当的切分。

如我们将见到的那样，软件系统短生命周期本质使这一切变的可行。

小结

系统应该是整洁的。侵害性架构会泯灭领域逻辑，冲击敏捷能力。当领域逻辑收到困扰，质量也就堪忧，因为缺陷更易隐藏，用户故事更难实现。当敏捷能力受到损害时，生产能力也会降低，TDD 的好处遗失殆尽。

在所有的抽象层级上，意图都应该清晰可辨。只有在编写 POJO 并使用这类方面的机制来无损的组合其他关注面时，这种事情才会发生，

无论是设计系统或单独的模块，别忘了使用大概可工作的最简单方案。

Comments: